With rapid development of internet technologies, the numbers of internet applications and users have increased sharply, and many problems and drawbacks with the TCP/IP-based internet have gradually appeared. Many countries have proposed plans for the next generation Internet, giving rise to software defined networks.
An OpenFlow software defined network consists of two parts: a data plane, for forwarding network data packets; and a control plane, for controlling strategies for the forwarding network data packets. Inside an OpenFlow switch of the data plane, a forwarding list, called a list describing virtual network flow rules, is maintained. This list describing virtual network flow rules can be matched based on the properties of Layer 1 (a physical layer) to Layer 4 (a transport layer) of the header of a data packet, and designate a method for processing data packets that match the items of the list describing virtual network flow rules. When a data packet has entered the OpenFlow switch, the OpenFlow switch will look up a list describing virtual network flow rules inside, and process the data packet according to the list describing virtual network flow rules. If there is no list describing virtual network flow rules inside the OpenFlow switch that can match the data packet, the OpenFlow switch will forward the data packet to an OpenFlow controller of the control plane, and the OpenFlow controller will then issue a list describing virtual network flow rules to the OpenFlow switch, for instructing the OpenFlow switch on how to process the data packet. The communication between the OpenFlow controller and the OpenFlow switch follows the OpenFlow protocol. The OpenFlow protocol defines uplink (from the OpenFlow switch to the OpenFlow controller) signallings and downlink (from the OpenFlow controller to the OpenFlow switch) signallings.
If an OpenFlow network is in the control of a plurality of OpenFlow controllers, each OpenFlow controller controls only a portion of specific data packets within the network. In this way, each OpenFlow controller controls a virtual network. However, in OpenFlow 1.0, each OpenFlow switch can have only one control logic, and therefore, data packets with different properties cannot be given to different OpenFlow controllers for processing. For this reason, it is necessary to add a network virtualization layer between an OpenFlow switch and an OpenFlow controller. This network virtualization layer receives the uplink signallings of all OpenFlow switches and, based on the properties of the uplink signallings, forwards them to corresponding OpenFlow controllers for processing. In the same way, the network virtualization layer also needs to process the downlink signallings issued by the OpenFlow controllers, and, after the processing, forward them to corresponding OpenFlow switches.
The specific implementation process of the network virtualization layer is as follows: a network virtualization platform sets up, for the network, a plurality of Slices that correspond to a plurality of virtual networks, assigns an OpenFlow controller to each Slice, and forwards data packets belonging to different Slices to corresponding OpenFlow controllers so as to realize network virtualization; and then adds a FlowSpace into each Slice. A FlowSpace describes the properties of the data packets forwarded to a Slice, at least including one or more of a plurality of the following Match items: a switch port (layer 1), source mac/destination mac or type of Ethernet (layer 2), source IP/destination IP or type of protocol (layer 3), and a TCP/UDP source port/destination port (layer 4); a PacketIn signalling is sent to the network virtualization platform after a network data packet enters an OpenFlow switch, the network virtualization platform matches the PacketIn signalling with the Match items in the FlowSpaces, if the PacketIn signalling matches a flow rule in a FlowSpace, then this PacketIn message is forwarded to the OpenFlow controller in which that FlowSpace is located.
The following drawbacks exist in the prior art:
1) The network virtualization platform conducts virtual network division based on each switch, each time a data packet enters an OpenFlow switch and a PacketIn is generated, the network virtualization platform will match the data packet with all FlowSpaces to determine which virtual network the data packet belongs to, after the data packet leaves the current switch and enters the next switch, the network virtualization platform will still match the data packet with all FlowSpaces to determine which virtual network the data packet belongs to. Thus, a virtual network determination is made for each hop. The efficiency is low.
2) The OpenFlow protocol allows a switch to perform flexible modification operations on data packets. After a data packet is operated on by a virtual network, part of the fields of the data packet may be modified. After this data packet enters another OpenFlow switch, it may be determined by the network virtualization platform as a data packet of another virtual network, which results in one data packet being controlled by the different OpenFlow controllers that correspond to the virtual networks. Data packet isolation is poor.
3) Although the network virtualization platform checks and modifies the Match items of lists describing the virtual network flow rules issued by the OpenFlow controllers that correspond to the virtual networks, it does not check the mutual exclusivity of the FlowSpaces, which causes that the lists describing virtual network flow rules issued by the OpenFlow controller that corresponds to virtual network 1 may match data packets that correspond to virtual network 2, resulting in signallings crossing the boundaries.
4) The network virtualization platform does not define physical extent of the virtual networks, which will lead to free propagation of virtual network data packets. The data packets do not have closure.